home *** CD-ROM | disk | FTP | other *** search
/ Acorn Risc Technologies StrongARM CD-ROM / Acorn Risc Technologies StrongARM CD-ROM.iso / ftp / documents / strongarm / guidelines < prev    next >
Encoding:
Text File  |  1996-07-26  |  3.9 KB  |  78 lines
  1. * Code written in C or BASIC will generally work, but see issues below.
  2.  
  3. * Code using the shared C library or Toolbox is generally fine. Using
  4.   RISCOS_Lib may cause problems, depending on the variant - re-linking
  5.   to a revised implementation will typically be sufficient. Anything linked
  6.   with ANSILib will not work. Products should _not_ be linked with ANSILib.
  7.  
  8. * Proprietary code squeezers may cause problems. Unsqueezed code or standard
  9.   squeezed code with AIF headers (eg code produced with our Squeeze system)
  10.   is generally fine. A new module, UnsqueezeAIF, detects squeezed images and
  11.   unsqueezes them itself with a negligible performance penalty.
  12.  
  13. * An application patcher will be supplied with RISC OS 3.7 that is capable
  14.   of detecting some known StrongARM-incompatible code sequences in an AIF image
  15.   and replacing them before the image is executed. This is only a temporary
  16.   solution though. If you find your software works only because the patcher
  17.   is patching it, you should modify it so it does not need patching.
  18.  
  19. * All Absolute files must have valid AIF headers. Absolute files without AIF
  20.   headers and untyped files are deprecated.
  21.   
  22. When writing in Assembler:
  23.  
  24. * Any self-modifying code or dynamically generated code is a problem. RISC OS
  25.   3.7 provides a SWI to support StrongARM synchronisation to dynamic code, but
  26.   the performance penalty is typically severe; cleaning the data cache will take
  27.   some time, and the entire instruction cache must be flushed. Hence, most cases
  28.   of dynamic code can no longer be justified, and should be reimplemented in a
  29.   static manner. One common reason for dynamic code is the calling of a SWI by
  30.   SWI code passed in a register. RISC OS 3.7 provides a new SWI which implements
  31.   this in an entirely static manner.
  32.  
  33. * The StrongARM pipeline is generally not a problem (even though it is now
  34.   5 levels deep rather than 3). The main issue is storing of the PC to memory
  35.   using STR and STM; this now stores PC+8 instead of PC+12. Code should be made
  36.   to work whether PC+8 or PC+12 is stored (so that ARM 6,7 are still supported).
  37.   Use of the PC in data processing instructions (MOV, ADD etc) remains
  38.   unaltered on StrongARM.
  39.  
  40. * STRB PC has an undefined result. This has sometimes been used as a shortcut
  41.   for storing a non-zero semaphore value in speed critical code. This
  42.   instruction should no longer be used. Use STR PC or STRB of some other
  43.   register.
  44.  
  45. Other differences at the assembler level, which affect RISC OS itself but
  46. are unlikely to affect applications are:
  47.  
  48. * StrongARM does not support 26 bit configuration. It does support 26 bit
  49.   mode within a 32 bit configuration.
  50.  
  51. * The control of architecture functions via coprocessor #15 is significantly
  52.   different. The requirements for context switching are significantly more
  53.   complex.
  54.  
  55. * The 'abort timing' (definition of values in affected registers) for data
  56.   aborts has changed.
  57.  
  58. * Reading from the processor vector area (words 00 to 1C inclusive) in
  59.   26 bit mode now causes an abort. In some circumstances this is trapped by
  60.   RISC OS 3.7 and the old behaviour simulated, but this must not be relied upon.
  61.  
  62. At the hardware level:
  63.  
  64. * When storing a byte, previous ARMs replicate the byte across the
  65.   entire 32 bit data bus. StrongARM only outputs the byte on the
  66.   relevant byte lane. The StrongARM processor card implements a compatibility
  67.   fix for pre-Risc PC style podules as follows: bytes stored to word aligned
  68.   addresses (byte 0) will be replicated on byte 2.  This should allow most podules
  69.   to work without firmware changes.
  70.  
  71. Backwards compatibility:
  72.  
  73. * Much StrongARM-ready code (especially in libraries, such as the aforementioned
  74.   revised RISC_OSLib) may use the new SWI-calling mechanism. Therefore a new module
  75.   "CallASWI" will be made available for use on RISC OS 3.1, 3.5 and 3.6 to provide
  76.   the SWIs OS_CallASWI, OS_CallASWIR12, OS_PlatformFeatures and
  77.   OS_SynchroniseCodeAreas.
  78.